1. Field of the Disclosure
The present disclosure relates to technology pertaining to log levels of transactions, and more particularly, to a method, computer system, and program product for dynamically adjusting a log level of a transaction.
2. Description of the Prior Art
In a data processing system, a transaction is a related task composed of units known as “success” and “failure”. For example, a transaction processing system (TPS) is typically a data processing system for storing and recording day-to-day business information and conducting day-to-day business, and the TPS usually consists of events, business procedures, and business activities. Normally, a process of processing a transaction involves creating or updating data and thus requires logging to enable tracking or troubleshooting. A detailed log of every transaction (or every record in a database) in the system adds to the use of system resources (for example, processing power, and the use of storage space and memory.)
Logs are recorded at different levels, according to debugging needs. The recorded Logs thus vary from level to level. For example, five consecutive log levels are configured, namely DEBUG, INFO, WARN, ERROR and FATAL, wherein DEBUG is the highest log level, whereas FATAL is the lowest log level. The higher the log level is, the more detailed the log is recorded. Of course, level can vary from system to system. For example, frameworks are recorded in Java at different severity levels (Visit http://en.wikipedia.org/wiki/Java_logging_framework).
The log level being set to DEBUG level is effective in investigating the underlying cause (root cause) of failure of a transaction. However, as described above, logs at DEBUG level have a disadvantage, which is that the DEBUG level logs need plenty of storage space for storing detailed data. In fact, most detailed data are likely to be unrelated to an issue under investigation, and logs at DEBUG level are likely to contain plenty of undesirable noise. The aforesaid drawback is especially obvious because, considering that a device for processing a transaction event is often provided with limited storage space for storing logs and the logs of successful transactions, the logs occupy most of the log space. To debug an issue with the data contained in a log, a system administrator has to spend much time digging into plenty of DEBUG level logs and identifying any logs related to an intended issue. Moreover, assuming that the space for storing logs is inadequate, the device is likely to delete old logs in order to reclaim space for use by a new log. In such a situation, some old but interesting logs are likely to be overwritten by new but useless logs.
Furthermore, when it comes to a system that processes a large amount of transactions concurrently, the big challenge is to identify the root cause of failure of a transaction just by investigating a created log. It is very likely that the failure of a transaction is a collateral result of any other preceding successful transaction. That is to say, the “dependency” between transactions remains unidentified.
There are two conventional solutions of the aforesaid problem. One of the solutions involves lowering the log level and thereby reducing the amount of logs, as disclosed in U.S. Pat. No. 8,156,387 entitled “Method and System for Error Manipulation,” for example. The other solution involves digging into plenty of logs to identify the intended ones, as disclosed in US Pub. 2006/0195731 and US Pub. 2008/0126828, for example. However, the present disclosure recognizes that no prior art discloses correlating concurrent transactions with each other according to the dependency between the transactions. Accordingly, the present disclosure realizes that it is imperative to identify the root cause of failure of a transaction efficiently by means of log data related to an aborted transaction.